In the area of digital systems, the task of accommodating increasing bus traffic continues to pose a challenge. The primary bottle-neck in most bus transactions appears to be the system bus. The system bus is a bottle-neck primarily because many devices share the same bus and must contend for its resources.
The PCI bus is a high performance, 32-bit or 64-bit bus with multiplexed address and data lines which can accommodate multiple high performance peripherals. The PCI Bus supports burst modes in which a bus transaction may involve an address phase followed by one or more data phases in tandem with a command phase followed by one or more byte enable phases. As such, an external device may require the use of the bus for multiple clock cycles during a bus transaction which can exacerbate bottle-neck problems associated with a system bus. Reference is now made to FIG. 1 which illustrates an overview of a computer system that utilizes the PCI bus. In FIG. 1, computer system 100 comprises host CPU 101, host memory 102, peripheral hardware controller 103, and bridge device 105. Peripheral hardware controller 103 is coupled to host CPU 101 and host memory 102 through PCI bus 104. More particularly, peripheral hardware controller 103 provides an interface between PCI bus 104 and external devices such as disk drivers, display monitors, parallel data port, local area network, wide area network, or the like.
In general, host CPU 101 and external devices may take turns controlling PCI bus 104 in carrying out transactions such as read and write transactions. While a device which takes control of PCI bus 104 to initiate the transaction is known as a "bus master" device, a device at the other end of the transaction is known as a "bus target" (or "slave") device. Information associated with bus transactions between devices include data, address, commands, byte enables, and identification of bus master and bus target device.
While a bus may be synchronous or asynchronous, PCI bus is a synchronous bus. In other words, information flowing from the bus master device to the target device and vice Versa are synchronized to a system clock such that a bus transaction must take place in an integral number of synchronized clock cycles. In carrying out bus transactions, bus protocols must be followed. These protocols consists mainly of bus mastership, requests for read or write transactions, and acknowledgment of such requests. PCI bus protocols can be found in "The PCI Local Bus Specification Rev 2.0", published by the PCI Special Interest Group, P.O. Box 14070, Portland, Oreg. 97214 and incorporated herein by reference.
Required tasks associated with synchronous PCI bus transactions such as address decoding, command decoding, and byte enable decoding must be generated based on the system clock. As a result, more than one system clock cycle may be required to acquire or capture data following a starting data phase signal by either a bus master or a bus target depending on whether a write or a read transaction is involved. Following a generation of a starting data phase signal requiring one clock cycle, one additional clock cycle may be required for byte enable information decoding. For example, a bus master may send byte enable information to a bus target during a first clock signal following a starting data phase signal, the bus target receives byte enable information and performs the necessary task of byte enable information decoding during a second clock cycle. The bus target then acquires data during a third clock cycle. The use of three clock cycles slows down the bus transaction as a result.
Another challenge presented by the PCI bus involves a requirement for zero nano-second hold time. To allow sufficient time for information related to a bus transaction (i.e., command, address, and data) to arrive at a destination, the "PCI Local Bus Specification" allows a set-up time, t.sub.su, of up to 7 nano-seconds from the time a bus transaction signal indicating the start of an information phase (e.g., address, data, command, etc.) is asserted until the next clock cycle begins. Moreover, once bus transaction data is made available, the "PCI Bus Specification" allows zero nano-second hold-time, t.sub.h, for a device to properly acquire bus transaction data until the beginning of a next clocking cycle. The failure to meet the zero-hold time requirement may lead to the capturing of invalid bus transaction information since a different information phase may begin in the following clock cycle. In other words, the zero nano-second hold-time requires bus transaction information to be preserved during the clock cycle in which that particular bus transaction information is put on a system bus.
Referring now to FIG. 2 which is a write transaction timing diagram illustrating set-up time, t.sub.su, and hold-time, t.sub.h. An exemplary timing diagram associated with a read transaction can be similarly derived. In FIG. 2, during clock cycle 1, signal IRDY# is asserted indicating the start of the data phase. However, required processing time may cause signal IRDY# to be asserted approximately at a middle part of clock cycle 1. At this point, data information is made available on the system bus. Bus transaction information is to be available by t.sub.su before the next rising clock edge. Once data information is made available, more than zero nano-seconds is needed to properly acquire the bus transaction information. As a result, the zero nano-second hold-time requirement as currently imposed by the "PCI Local Bus Specification" is unresolved.